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(54) IEEE-1394 serial bus network capable of multicast communication 



(57) In a communication network where IEEE-1394 
nodes are connected to a serial bus. each node func- 
tions as a source or a destination for signaling an asyn- 
chronous channel setup request containing a multicast 
address and signaling an asynchronous channel 
release request. A multicast manager, connected to the 
bus. includes a channel allocation table having a 
number of entries each mapping a channel number to a 
multicast addi'ess. The multicast manager responds to 
the setup request for making a search through the allo- 
cation table, setting a node count value to 1 , acquiring 
ownership of a channel number from an isochronous 
resource manager and mapping the acquired channel 
number to the multicast address of the request in a cor- 



responding entry of the allocation table if no channel 
number was mapped to the multicast address or incre- 
menting the node count value by 1 if a channel number 
is mapped to the multicast address, and then signaling 
a reply message. The source node responds to this 
reply message by multicasting asynchronous stream 
packets to the serial txjs. The multicast manager further 
responds to tiie asynchronous channel release request 
for decrementing the node count value by 1 . When the 
node count value equals zero, the ownership of the 
channel number is restored to the isochronous resource 
manager and the corresponding entry of the channel 
allocation table is cleared. 
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Description * 

BACKGROUND OF THE INVENTION 
Reld of the Invention 



[0001] The present invention relates generally to 
lEEE-1394 serial bus systems and more specifically to 
a serial bus communication on which multicast packets 
are transmitted over an assigned channel. 

Description of the Related Art 

[0002] IEEE Standard tor a High Performance Serial 
Bus (IEEE Std. 1394-1995) specifies broadcast com- 
munication using a particular address reserved for this 
purpose as well as unicast communication by specifying 
a target node with an identifier assigned to ttiat node. 
Asynchronous and isochronous data transfer types are 
available for different types of traffic. Control data traffic 
is supported by asynchronous packets, while high-vol- 
ume traffic is carried on isochronous packets at a con- 
stant rate. 

[0003] Study is currently undertaken by a txxiy known 
as IETF (Internet Engineering Task Force) to enable 
transmission of connectionless packets such as IP 
(Internet Protocol) datagrams over the IEEE-1394 serial 
bus. According to the proposed method for sending a 
datagram to a destination node having an IP address, 
the source node first k)roadcasts the IP address of the 
destination node to all nodes of the bus. A node having 
the broadcast address knows that it is targeted and 
returns a node identifier corresponding to that IP 
address to the source node. At the source node, the 
informed node identifier is registered as a destination 
address of an asynchronous packet, which is transmit- 
ted as an IP datagram. While all nodes of the bus can 
be addressed with the specified broadcast address and 
each node can be specified for unicast transmission, it 
is currently impossible to specify a particular group of 
nodes for multicast transmission. 
[0004] Asynchronous stream packets are defined by 
the IEEE-1394 standard as a special case of asynchro- 
nous transmission. Similar to the isochronous packet, 
the asynchronous stream packet uses a channel 
number rather than a destination node address. It can 
be transmitted as a multicast packet during a lairness 
interval". Possibility thus exists that a single channel is 
shared by more than one node. In such a multicast 
mode, however, there is a need to provide some means 
for communicating the channel number of either asyn- 
chronous stream packets or isochronous packets 
between nodes for the purpose of dynamically setting or 
releasing a channel. 

SUMMARY OF THE INVENTION 

[0005] It is therefore an object of the present invention 
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to provide a communication network and a method to 
implement multicast communication for IEEE-1394 

nodes. 

[0006] According to one aspect, the present invention 

5 provides a network comprising a plurality of IEEE-1394 
nodes connected to a serial bus. each of the nodes 
functioning as a source node or a destination node for 
signaling an asynchronous channel setup request con- 
taining a multicast address and signaling an asynchro- 

10 nous channel release request. A multicast manager is 
connected to the serial txjs. The multicast manager 
comprises a channel allocation table having a plurality 
of entries each mapping a channel number to a multi- 
cast address. The multicast manager is responsive to 

15 the asynchronous channel setup request for makir>g a 
search through the table, setting a node count value to 
1. acquiring ownership of a channel number from an 
IEEE*1394 isochronous resource manager and map- 
ping the acquired channel numk>er to tiie multicast 

20 address of the request in a conesponding entry of the 
allocation table if no channel number was mapped to 
the multicast address during the search or incremerrting 
the node count value by 1 if a channel number is 
mapped to the multicast address, and then signaling a 

25 reply message. The source node is responsive to the 
reply message from the multicast manager for multi- 
casting asynchronous stream packets to the serial bus. 
The multicast manager is further responsive to tiie 
asynchronous channel release request for decrement- 

30 ing the node count value by 1. When the node count 
value equals zero, the multicast manager restores tiie 
ownership of the channel number to the isochronous 
resource manager and clears tiie corresponding entry 
of the channel allocation table. 

35 [0007] .'According to a second aspect, the present', 
invention provides a communication network compris- 
ing a plurality of IEEE-1 394 nodes connected to a serial 
bus/ each of the nodes functioning as a source node or 
a destination node for signaling an isochronous channel 

40 setup request containing session data and signaling an 
isochronous channel release request, and a multicast 
manager connected to the serial bus. The multicast 
manager comprises a channel allocation table having a 
plurality of entries each mapping a channel number to 

45 session data. The multicast manager is responsive to 
the isochronous channel setup request for making a 
search through the table, setting a node count value to 
1 . acquiring ownership of a channel number and neces- 
sary channel resource from an IEEE-1394 isochronous 

50 resource manager and mapping the channel number 
and the necessary channel resource to the session data 
of the request in a conesponding entry of tiie table if no 
channel number was mapped to the session data during 
the search or incrementing the node count value by 1 if 

55 a channel number is mapped to the session data during 
the search, and signaling a reply message. The source 
node is responsive to the reply message for multicasting 
isochronous packets to the bus. The multicast manager 
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is responsrve to the isochronous channel release packet 
for decrementing the node count value by 1 . Whei the 
node count value equals zero, the multtcast manager 
restores the ownership of the channel number and the 
channel resource to the isochronous resource manager 5 
and clears the corresponding entry of the table. 
[0008] According to a further aspect the present 
invention provides a communication network compris- 
ing a plurality of IEEE-1394 nodes connected to a serial 
bus. each of the nodes functioning as a source node for 10 
signaling a path message indicating session data and 
functioning as a destination node for receiving the path 
message and signaling a first isochronous channel 
setup request containing the session data indicated in 
the path message, each of the source and destination is 
nodes signaling an isochronous channel release 
request and a multicast manager connected to the 
serial bus. The multicast manager comprises a channel 
allocation table having a plurality of entries each map- 
ping a channel number to session data. The multicast 20 
manager is responsive to the first isochronous channel 
setup packet for making a search through the table, set- 
ting a node count value to 1 . acquiring ownership of an 
isochronous channel number from an IEEE-1394 iso- 
chronous resource manager and mapping the acquired 25 
channel number to the session data of the packet in a 
con'esponding entry of the table if no channel number 
was mapped to the session data during the search or • 
incrementing the node count value by 1 if a channel 
number is mapped to the session data during the 30 
search, and signaling a first reply message. The desti- 
nation node is responsive to the first reply message for 
signaling a reservation message indicating- a desired 
channel resourcerand the source node is responsive to -. 
the reservation message for signaling' a" second iso^ 35 
chronous channel setup request containing the channel • 
resource indicated . in the reservation .message. The', 
multicast manager is responsive to the second iso- 
chronous channel setup request for determining neces- . 
sary channel resource from a resource value in the 40 
corresponding entry of the allocation table, acquiring 
ownership of the necessary channel resource from the 
isochronous resource manager and updating the 
resource value with the acquired channel resource and 
signaling a second reply message. The source node is 45 
responsive to the second reply message from the multi- 
cast manager for multicasting isochronous packets to 
the bus. The multicast manager is responsive to the iso- 
chronous channel release request for decrementing the 
node count value by 1. When the node count value so 
equals zero, the multicast manager restores the owner- 
ship of the channel number and the channel resource to 
the isochronous resource manager and clears the cor- 
responding entry of tiie table. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] The present invention will be described in fur- 



ther detail with reference to the accompanying draw- 
ings, in which: 

Fig. 1 is a block diagram of an IEEE 1394 serial bus 
network embodying the present invention; 
Fig. 2 is an illustration of a channel allocation table 
reskfent in a multicast manager: 
Rg. 3 is an illustration of an control register resident 
in the multicast oanager to be directly set t}y a 
requesting rKxJe and read by the multicast manager 
when estak>lishfng an asynchronous multicast- 
mode channel or an isochronous multicast-mode 
channel; 

Rg. 4 is an illustration of an corrtrol register resident 
in an IEEE-1 394 node to be directly set by ttie mul- 
ticast manager and read by the requesting node 
when establishing an asynchronous muKicast- 
mode channel or an isochronous multicast-mode 
channel; 

Rg. 5A is a flowchart of tiie operation of a source 
node of the network when requesting the transmis- 
sion of multicast asynchronous stream packets 
according to a first emt>odiment of the present 

invention; 

Rg. 5B is a flowchart of tiie operation of a destina- 
tion node when requesting the reception of multi- 
cast asynchronous stream packets according to the 
first embodiment of the present invention; 
Fig. 6 is a flowchart of the operation of the multicast 
manager co-operating with requesting nodes which 
operates according to the flowchart of Fig. 5; 
Figs. 7 to 10 are sequence diagrams illustrating 
asynchronous fransactions associated witii tiie 
flowcharts of Figs. 5 and 6; 

Figs. 11 A and 1 1 B are ftowcharts of the operation - 
of a source node requesting an isochronous chan--^ 
nel according to a second emtxxjiment of tiie 
present invention; 

Fig. 12 is a flowchart of the operation of a destina- 
tion node requesting the reception of multicast iso- 
chronous packets according to the second 
embodiment of the present invention; 
Rg. 13 is a flowchart of the operation of the multi- 
cast manager co-operating with the nodes operat- 
ing according to the flowcharts of Figs. 11 A, 118 
and 12; and 

Rgs. 14 to 16 are sequence diagrams illustrating 
isochronous ti^ansactions associated with tiie flow- 
charts of Figs. 11 A, 118. 12 and 13. 

DETAILED DESCRIPTION 

[0010] In Fig. 1. a typical example of the IEEE 1394 
serial bus system is illustrated, in which five nodes 10A 
to 10E are provided. Each node has a communication 
protocol such as the Internet Protocol. In the following 
description, the node 10A will be explained as a source 
node. IOC as a destination node with the intermediate 
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node 10B functioning as a repeater between nodes 10A 
and 10C. Node IOC also functions as a repeater when 
a packet (asynchronous) is exchanged between nodes 
10A and 10D. Node 10D is a mufticast manager that 
performs the management of channels allocated for 5 
multicast communications and quality-of-service 
parameters (such as the bandwidth of allocated chan- 
nels) by cooperating with a node 1 0E that assumes the 
role of an isochronous resource manager Note that 
these manager functions may be combined and imple- w 
mented in a single node. Although not shown in Fig. 1 . 
each node has a physical layer connected to the 1394 
serial bus. a link layer, and a transaction layer. The link 
layer is connected to an application layer for iso- 
chronous transactions as well as to the transaction layer js 
for asynchronous transactior^s. 
[0(h 1] According to the present invention, the multi- 
cast manager 10D is provided with a channel allocation 
table 20. as illustrated in Rg. 2. Channel allocation table 
20 has a plurality of channel entries corresponding to 20 
channel numbers "0" to **63". 

[0012] Each channel entry of the channel allocation 
table 20 is divided into fields 21 to 24. Reld 21 is a 
packet type field that is used for indicating whether the 
packet to be used for a data transfer is an isochronous 25 
packet that is transmitted at a constant rate in a multi- 
cast mode within nominal cycle period of 125 ^s or an 
asynchronous stream packet that is transmitted in a 
multicast mode within an interval known as "fairness 
intervar between two arbitration reset gaps. Field 22 is 30 
a bandwidth field in which allocated t>andwidth is \n6\- 
cated if the packet is of isochronous type. A node count 
is given in the field 23 to indicate the number of nodes 
partidpating in a single data transfer, regardless of the 
types of packets being used. Field 24 is an address field 35 
in which a multicast address is indicated if data transfer 
involves the use of asynchronous stream packets. If 
data transfer mo6e is isochronous, session data (desti- 
nation node address, protocol number and port number) 
are indicated in the address field 24. 40 
[001 3] Multicast manager 1 0D is further provided with 
a control register 30 as shown in Fig. 3. Control register 
30 is defined in the GSR (control and status register) 
architecture register space of the IEEE 1394 standard 
and has a command field 31 for giving one of a prede- 45 
fined set of indications (asynchronous-mode channel 
setup and release and isochronous-mode channel 
setup and release) and an address field 32 in which a 
multicast address is indicated when data transfer mode 
is asynchronous or session data (destination node so 
address, protocol number and port number) when the 
transfer mode is isochronous. Control register 30 is writ- 
ten directly by a node requesting the starting or ending 
of a communication and the multicast manager 10D 
reads the contents of the register 30 and knows that a ss 
request is made from one of the nodes of the network. 
[DDI 4] Each of the nodes 1 0A to 1 0C is provided with 
a control register 40. which is also defined in the CSR 




architecture register space, as shown in Fig. 4. This 
control register has a response field 41 . an address field 
42 and a channel number field 43. Response field 41 is 
used to indicate multicast (asynchronous-mode) chan- 
nel setup indication or isochronous-mode channel setup 
indication, and the address Held 42 is used to store a 
multicast address in the case of asynchronous mode 
and session data during isochronous transfer mode. 
Control register 40 of each node is directly written by the 
multicast manager 10D and the node reads the con- 
tents of the register 40 and knows that a response 
action is taken by the multicast manager 10D. 
[001 5] Fig. 5A is the flowchart of the operation of the 
transaction layer of source node 10A when transmission 
of asynchronous stream packets is initiated from the 
application layer of the node, and Rg. 5B is the flow- 
chart of the operation of the transaction layer of destina- 
tion node IOC when reception of such multicast packets 
is requested from tiie application layer of the node. 
[0016] Specifically, in Fig. 5A. the transaction layer at 
the source node checks for the presence of IP multicast 
data from tiie application layer software (step 501). If IP 
multicast data is detected, the transaction layer pro- 
ceeds from step 501 to step 502 to send a request con- 
taining a multicast address for setting up an 
asynchronous-mode channel. This is done by directiy 
setting the control register 30 of the nnulticast manager 
10D with an asynchronous mode indication and a multi- 
cast address. Multicast manager 10D knows that it has 
received a request from a node, and sends a reply to 
the requesting node. This is achieved by the multicast 
manager 10D by directiy setting the control register 40 
of the requesting ^node with a response indication, the 
multicast address 'Of the node and a channel number 
obtain^ from. the isochronous resource manager 10E. 
When the reply indication is set in the control register 40 
(step 503), the source node 10A is conditioned to send 
asynchronous stream packets containing tiie assigned 
channel number in their channel numt>er field. At step 
504, an asynchronous stream packet is sent during a 
"fairness interval" which is designed into the transaction 
layer of the node by the 1394 Standard so that each 
node wishing to initiate a transaction is given fair access 
to the bus. 

[001 7] Following the transmission of an asynchronous 
stream packet, a timer is started (step 505) and a test is 
made at step 506 for the presence of an outstanding 
asynchronous stream packet of the same nrujlticast 
address as one transmitted at step 504. If there is one. 
the dedsion at step 506 is affirmative smd flow proceeds 
to step 507 to clear the timer and returns to step 504 to 
repeat the asynchronous stream packet transmission, 
timer start-up and packet presence test. If there is no 
outstanding asynchronous stream packet, tiie decision 
at step 506 is negative and flow proceeds to step 508 to 
check to see if the timer has timed out. If the timer is still 
running, flow loops steps 506 and 508 so that, if an 
asynchronous stream packet occurs before the timer 
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times out. 'it is transmitted in a fairness irrterval. If the 
timer times, it is concluded that there are no more pack- 
ets to transmit and flow proceeds from step 508 to step 
509 to set a channel release indication into the control 
register 30 of the multicast manager 10D. 
[001 8] in Fig. 5B. the operation of the destination node 
IOC begins at step 51 1 when the transaction layer of the 
node receives a data reception indication from its appli- 
cation layer. The transaction layer of node IOC pro- 
ceeds from step 511 to step 512 to send a request 
containing a multicast address for setting up an asyn- 
chronous-mode channel- This is done by directJy setting 
the control register 30 of the multicast manager 10D 
with an asynchronous mode indication and a multicast 
address in the same manner as performed by the 
source node at step 502. Multicast manager 10D knows 
that it has received a request from a node, and sends a 
reply to the destination node. This Is also achieved by 
the multicast manager by directiy setting the control reg- 
ister 40 of the destination node with a response indica- 
tion, the multicast address of the destination node and a 
channel number obtained from the isochronous 
resource manager 10E. When the reply indication is set 
in the control register 40 (step 513), the destination 
node IOC is conditioned to receive asynchronous 
stream packets containing the assigned channel 
number in their channel number field (step 514). If an 
end-of-reception indication is given by the application 
layer of the destination node (step 515). the transaction 
layer terminates the routine by setting a channel release 
indication into the control register 30 of the multicast 
manager (step 516). 

[0019] The operation of the multicast manager 10D in 
I i-' v- response to the requests for asynchronous stream 
. . Cr-'- packets from the source and destination nodes will be 
: I explained with the aid of the flowchart of Rg. 6. 
. . ;r: [0020] Multicast manager 10D starts its operation at 
- - step 601 at which it checks to see if an asynchronous- 
mode channel setup request or an asynchronous-mode 
channel release request is received from a node. This is 
achieved by checking the contents of the control regis- 
ter 30 to see whether necessary data are set by a 
requesting node. If an asynchronous-mode channel 
setup indication is set in the register 30. flow proceeds 
from step 601 to step 602 to make a search through the 
channel allocation talsle 20 for a channel entry in which 
received multicast address is registered. 
[0021 ] If there is no channel entry containing that mul- 
ticast address, flow proceeds from step 603 to step 604 
to send a channel assignment request to the iso- 
chronous resource manager 10E to acquire ownership 
of a channel. If a channel is available, a channel number 
is assigned by the isochronous resource manager and 
the multicast manager 10D is informed of the assigned 
channel number. 

[0022] At step 605. an asynchronous packet type indi- 
cation is set into the packet type field 21 off a channel 
entry of the allocation table 20 that corresponds to the 



assigned channel number arvi the multicast address 
stored in ttie control register 30 is set into the address 
field 24 of that channel entry and a "1" ts set into the 
node count field 23. In this way. a channel number is 
5 mapped to tiie multicast address of em asynchronous 
channel setup request. 

[0023] At step 606. the multicast manager sends a 
reply packet to the source node to inform it of tiie chan- 
nel number nnapped in the corresponding entry of the 
10 allocation table 20. and returns to the starting point of 
the routine. 

[0024] If an asynchronous-mode channel setup 
request is received from another node, the multicast 
manager will repeat steps 602 and 603. so that a new 

75 multicast address is set by that node into the address 
field 32 of register 30. If tiie new multicast address is the 
same as the one set in the address f iekl 24 of allocation 
table 20. the decision at step 603 will be affirmative, and 
fbw proceeds to step 607 to inaement tiie value of 

20 node count field 23 by one. and proceeds to step 606 to 
send a reply message to the requesting node by setting 
its control register 40 with the channel number already 
assigned to the node 10A. In this manner, the node 
count value represents the number of nodes using the 

25 same asynchronous channel. 

[0025] If tiie source node ceases to send asynchro- 
nous stream packets, it sends a channel release 
request by setting the confrol register 30 with a release. ~ 
indication (step 509, Fig. 5A). In a similar manner, when 

30 the destination node ceases to receive asynchronous 
stream packets, it sends a channel release request by 
setting the conti^ol register 30 with a release indication 
(step 516. Fig. 5B). . . v.- ..r; 

[0026] In response to each of such release > requests,- 

35 the multicast manager 100, which is looping step 601 ;. . 
proceeds to step 608 to decrement the. value in. the 
node count field 23 by one and checks to see if the node 
count equals zero* (step 609). If the node count is not 
equal to zero, flow returns from step 609 to step 601; If. 

4o the node count is zero, flow proceeds to step 610 to 
send a channel release packet to the isochronous 
resource manager 10E to restore the ownership of tiie 
assigned channel, and concludes the routine with step 
61 1 by clearing the contents of the appropriate channel 

45 entry of allocation table 20. 

[0027] The operation of tiie asynchronous transac- 
tions will be fully understood by the following description 
with the aid of the sequence diagrams of Figs. 7 to 10. 
[0028] In Fig. 7, when the application layer of source 

50 node 10A generates IP multicast data 71 . its transac- 
tion layer sends an asynchronous-mode channel setup 
packet 72 to the multicast manager 10D. In response, 
the multicast manager searches the channel allocation 
table 20 and sends a channel request 73 to the iso- 

55 chronous resource manager 10E if no channel number 
is assigned to the multicast address sent with tiie setup 
packet from node 10A. If the source node 10A is the first 
to send the asynchronous-mode channel setup packet. 
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a channel nurfft>er is assigned and informed to the mul- 
ticast manager 10D via a reply packet 74. Multicast 
manager 100 sets a "1" into the node count field of the 
allocation table and sends a reply packet 75 to the 
source node 10A to inform it of the assigned channel 
nunt^er. Source node 10A sends asynchronous stream 
packets 76 during fairness intervals to the application 
layer of destination node IOC. using the assigned chan- 
nel. 

[0029] In Fig. 8. with an asynchronous channel being 
established as described above, if the application layer 
of another source node generates IP multicast data 81 . 
its transaction layer sends an asynchronous-mode 
channel setup packet 82 to the multicast manager 10D. 
containing the same multicast address as that used by 
the node 10A. In response, the multicast manager 
searches the channel allocation table 20. knows that the 
multicast address just received is already assigned a 
channel number, increments the node count by one and 
sends a reply packet 83 to the new source node to 
inform it of the already assigned channel number. The 
new source node sends asynchronous stream packets 
84 during fairness intervals to the application layer of 
destination node IOC. using the assigned channel. 
[0030] In Fig. 9, when the application layer of destina- 
tion node 10C gives an indication 91 to the transaction 
layer that IP multicast data be received from a source 
node, the transaction layer serxls an asynchronous- 
mode channel setup packet 92 to the multicast manager 
10D. containing a multicast address. In response, the 
multicast manager searches the channel allocation 
table 20 and sends a channel request 93 to the iso- 
chronous resource manager 10E if no channel number 
is assigned to4he multicast address sent with the setup 
packet from node 1 0C. If the destination node 1 0C is the 
first to serxi the asynchronous-mode channel setup 
packet, a channel -number is assigned and informed .to 
the multicast manager 10D via a reply packet 94. Multi- 
cast manager 10D sets a "1 " into the node count field of 
the allocation table and sends a reply packet 95 to the 
destination node IOC to inform it of the assigned chan- 
nel number. Destination node 10C is now ready to 
receive asynchronous stream packets which contains 
the channel number indicated by the reply packet 95 
from the multicast manager 10E. 
[0031 ] In Fig. 1 0. when the application layer of another 
destination node gives an indication 101 to its transac- 
tion layer that IP multicast data be received from a 
source node, the transaction layer sends an asynchro- 
nous-mode channel setup packet 102 to the multicast 
manager 10D, containing a multicast address. In 
response, the multicast manager searches the channel 
allocation table 20 and knows that the multicast address 
just received is already assigned a channel number, 
and it increments the node count by one and serxls a 
reply packet 103 to the new destination node to inform it 
of the already assigned channel number. 
[0032] The value in the node count field 23 of alloca- 
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tion table 20 in the multicast manager 10D is decre- 
mented by one in response to an asynchronous-mode 
channel release packet received from the transaction 
layer of a source node if asynchronous sti'eam packets 
are not transmitted for a predetermined interval or from 
tiie transaction layer of a destination node if it is notified 
with an end-of-communication indication from the appli- 
cation layer of ttie node. When the node count value is 
reduced to zero, the nrulticast manager requests the 
isochronous resource manager to release the asyn- 
chronous multicast channel. 

[0033] Rgs, 1 1 A and 1 1B are the flowcharts of tfie 
operation of the link layer of source node 10A when 
transmission of nrulticast isochronous packets is initi- 
ated from the application layer of the node, using a 
bandwidth control protocol such as RSVP (resource 
reservation protocol). Rg. 12 is the flowchart of tiie 
operation of the link layer of destination rKxie IOC when 
reception of such isochronous packets is requested 
from the application layer of the node IOC. 
[0034] In Fig. 1 1 A. the application layer of node 10A 
sends a message known as "path** message to the 
application layer of destination node IOC to inform it of 
path data of the source-destination communication link 
(step 1101). 

[0035] In Fig. 12. when tiie application layer of node 
IOC receives the path message from the source node 
10A. it applies a session (isochronous-mode) channel 
setup indication to the link layer (step 1201). \Nhen tine 
link layer receives this session setup indication (step 
1202). it sends a session setup request to tiie multicast 
manager 10D by setting its control register 30 with an 
isochronous channel setup indication (step 1203). If tiie 
request is granted, a channel number-is sent from tiie : 
multicast manager with a reply message which .is set 
into the control register 40 of node IOC (step 1204):. . v-:^kj. i^ 
Therefore, a channel setup indication, session data, j^'^p ^i: 
(destination node address, protocol number and port ' r 
number) and the assigned channel number are respec- -^-v* ' * 
tively stored in the fields 41. 42 and 43 of control regis- 
ter 40. 

[0036] Flow proceeds to step 1 205 to send a reserva- 
tion message from the application layer of destination 
node IOC to the application layer of source node 10A. 
indicating the bandwidth the destination node wishes to 
receive through the assigned channel. Reservation is 
"refreshed*" by repeatedly transmitting reservation mes- 
sages. For this purpose, a timer is started (step 1206) 
following the execution of step 1205. 
[0037] At step 1207, the reception of a session 
release indication from the application layer is checked. 
If the decision at step 1207 is negative, the timer is 
checked at step 1208 for expiration. When the timer 
expires, flow returns from step 1208 to step 1205 to 
repeat the transmission of a reservation message and 
start the timer again. 

[0038] When no reservation message is transmitted 
during the time-out period of the timer, a session 
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release indication will be issued from the application 
layer and flow exits the loop and enters step 1209 to ter- 
minate the routine by sending a session release request 
from the destination node lOC to the multicast manager 
10D by appropriately setting its control register 30. 
[0039] Returning to Fig. 1 1 A. a reservation message 
from the destination node is received by the application 
layer of the source node and a session channel setup 
Indication is issued to the link layer (step 1 102). 
[0040] At step 1 103. the source node 10A sends a 
session channel setup request to the multicast manager 
10D for requesting the bandwidth desired by the desti- 
nation node 1 DC. This is done by setting the control reg- 
ister 30 of manager 10D with the session data and the 
bandwidth data received with the reservation message 
from the destination node. If the request is granted, a 
reply packet is transmitted from the multicast manager 
to the source node where the control register 40 Is set 
with the assigned channel number (step 11 04). 
[0041 ] At step 1 105. the source node begins sending 
isochronous packets with the assigned channel number 
to the destination node. 

[0042] After sending isochronous packets, the source 
node checks to see if session release indication is 
received from its application layer (step 1111, Fig. 1 1 B). 
If so, flow proceeds to step 1112 to send a session 
release request to the multicast manager 10D by setting 
its control, register 30 with a session release indication 
and the session data. 

[0043] The operation of the multicast manager 10D in 
response to the request for isochronous packets will be 
explained with the aid of the flowchart of Rg. 13. 
. [0044] ' The operation of multicast manager 10D 
begins with step 1301 by :checking:the;receipt of a ses- 
^sion setup request or a sesision release request from 
the destination node IOC by examining its control regis- 
ter 30:. When a session setup request is/received from 
the destination node 1 0C; flow proceeds from step 1 301 
to step 1302 to search through.the channel allocation, 
table 20 for a channel entry in which the session data 
now stored in the control register 3D are registered. If 
they are not registered in the allocation table (step 
1303) flow proceeds to step 1304 to send a request to 
the isochronous resource manager 10E to acquire own> 
ership of a channel number. When a channel number is 
granted from the isochronous resource manger the mul- 
ticast manager proceeds to step 1305 to set an iso- 
chronous packet type indication into the packet type 
fleki 21 of the allocation-table channel entry corre- 
sponding to the assigned channel number, a "1" into the 
node count field 23 and session data into the address 
field 24 (step 1306). Following the execution of step 
1305, flow proceeds to step 1306 to send a reply mes- 
sage to the destination node by setting its control regis- 
ter 40 with the assigned channel numt>er. and then 
returns to the beginning of the routine for looping steps 
1301 and 1310 to check for the arrival of a further 
request from a source or a destination node. 



[0045] K the decision at step 1303 is affirmative in 
response to receipt of a sut>sequent packet from 
another destination node, the node count value of the 
allocation tat)te 20 is incremented by one at step 1307 

5 and a reply message containing the assigned channel 
number is set irrto the control register 40 of the request- 
ing destination node (step 1306). 
[0046] The application layer at the destination node 
IOC will then repeatedly send a reservation message to 

10 the application layer of source node 10A to inform the 
bandwidth the destination node is ready to receive (step 
1206, Fig. 12). In response to each reservation mes- 
sage, the source node 10A sends a session setup 
request to the multicast manager 10D according to the 

IS resource reservation protocol (steps 1 101 to 1 103, Rg. 
11 A). 

[0047] The session setup request from the source 
node 10A is detected at step 1310. Since the resource 
reservation protocol is a receiver-oriented protocol, tiiis 

20 request contains the bandwidth the destination node 
IOC is ready to receive as well as the session data. In 
response to this request the multicast manager 10D 
proceeds to step 1311 to compare the bandwidth 
requested by the destination node with a value cunrentiy 

25 set in the bandwidth field of the conesponding entry of 
allocation table 20. 

[0048] If the source node 1 0A is the first to send a path 
message for the current session, the value set in tiie 
bandwidth fed of the corresponding entry is zero, and 

30 hence the decision at step 1311 is negative and flow 
proceeds to step 1312 to secure ownership of the 
requested t>andwidth from tiie isochronous resource 
manager ' 10E. When the requested bandwidth 'is, 
granted, the bandwidth field of the corresponding alio-?-. 

35 cation channel entry is updated with the granted xhanf^ 
nel resource (step 1313). Flow proceeds to step 1306 to ' 
send a reply message to the source node 1 0A to inform; 
the assigned channel number. This channel number . 
and tiie corresponding session data are set .into the 

40 control register 40 of tiie source node. 

[0049] If the source node 1 0A is not the first to send a 
path message, the compared values at step 1311 may 
be equal to each other, and flow returns from step 131 1 
to step 1306 to send a reply message to the source 

45 node to indicate the channel number which already 
been assigned. If the requested t>andwidth is greater 
than tiie currently allocated value, the multicast man- 
ager determines the deficit channel resource and 
request it from the isochronous resource manager (step 

50 1312). updates the bandwidth field of the corresponding 
channel entry (step 1313) and informs the source node 
of the channel number and the session data (step 
1306). If the requested bandwidth is smaller than tiie 
currently allocated value, tiie multicast manager deter- 

55 mines a surplus value and restores the ownership of the 
surplus resource to tiie Isochronous resource manager 
(step 1312) and updates the bandwidth field of the cor- 
responding channel entry (step 1313) and proceeds to 
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st^ 1306 to inform the channel nurrtier and session 
data. 

[0050] At the end of a session, either a source node 
or a destination node issues a session release request. 
After looping steps 1301 and 1310, the multicast man- s 
ager 10D proceeds exits from step 1301 in response to 
receipt of a session release request from a destination 
node or from step 1310 in response to receipt of a ses- 
sion release request from a source node and enters 
step 131 4 to decrement the node count value by one. io 
[0051 ] At step 131 5, the node count is examined. If it 
is not equal to zero, flow returns to step 1301. Other- 
wise, flow proceeds to step 1316 to send a channel 
release message to the isochronous resource manager 
10E to restore the ownership of the assigned channel, is 
and terminates the routine after clearing the corre- 
sponding channel entry of the allocation table 20 (step 
1317). 

[0052] The operation of the isochronous transactions 
will be fully understood by the following description with 20 
the aid of the sequence diagrams of Rgs. 14 to 16. 
[0053] In Fig. 1 4, the application layer of source node 
10A initially transmits a "path" message 1401 to the 
application layer of destination node IOC. which 
responds by issuing to its link layer a session setup irrdi- 25 
cation 1402. The link layer of destination node IOC 
sends a session (isochronous-nxxie) cheinnel setup 
packet 1 403 to the multicast manager 10D. In response, ' 
the multicast manager searches the channel allocation 
table 20 and sends a channel request 1404 to the iso- 30 
chronous resource manager 10E since no channel 
number is assigned to the session. A channel number is 
assigned by the isochronous resource manager and ' 
informed to. the multicast manager 10D via a reply 
packet 1405. Multicast manager 10D sets a "1** into the 35 
node count field of allocation table 20 and sends a reply 
packet 1406 to the destination node IOC to inform it of 
the assigned channel number. A reservation message 
1407 is then sent from the application layer of destina-. ' 
tion node 1 0C to the application layer of source node 4o 
10A to inform it of tiie bandwidth the destination node 
wishes to receive. 

[0054] The application layer of source node 10A 
issues a session setup indication 1408 to its link layer, 
which responds with the transmission of a session 45 
channel setup packet 1409 to the multicast manager for 
requesting the bandwidtii desired by the destination 
node IOC. Multicast manager 10D requests with a mes- 
sage 1410 to the isochronous resource manager to 
obtain the necessary bandwidth with a reply message so 
141 1. The allocated bandwidth is informed with a reply 
packet 1412 to the requesting source node 10A. whose 
application layer is now conditioned to send iso- 
chronous packets 1413 at constant rate to the applica- 
tion layer of destination node IOC. Destination node 55 
IOC receives isochronous packets if they contain the 
same channel number and session values as tiiose 
indicated by the reply packet 1406. 




[0055] In Fig. 15, with a session being established as 
described above, if the application layer of another 
source node sends a "path" message 1 501 to the desti- 
nation node IOC. the link layer of destination node IOC 
sends a session channel setup packet 1503 to tiie mul- 
ticast manager lOD in response to a session setup indi- 
cation 1502 from the application layer of node IOC. 
Multicast manager then searches the channel allocation 
table 20 and sends no channel request to the iso- 
chronous resource manager since a channel number 
has been assigned to the session. Multicast manager 
10D increments the node count by one and sends a 
reply packet 1504 to the destination node IOC to inform 
it of the assigned channel number and the session val- 
ues (source node address, protocol number and port 
nun^er). A reservation message 1505 is then sent from 
the application layer of destination node IOC to the 
application layer of source node to inform it of the t^nd- 
width it wishes to receive. The application layer of 
source node responds with a session setup indication 
1506 issued to its link layer, which responds with the 
transmission of a session channel setup packet 1507 to 
the multicast manager for requesting the bandwidth 
desired by the destination node IOC. Multicast manager 
10D requests with a message 1508 to the isochronous 
resource manager to increase or decrease the allocated 
bandwidth depending on the bandwidth requested by 
the destination node. The reallocated bandwidth is com- 
municated wrtii a reply message 1509 to the source 
node, whose application layer is now conditioned to 
send isochronous packets 1510 at constant rate to tiie 
application layer of destination node. Destination node 
receives isochronous packets if they contain the same 
channel numbenand session values as those Indicated 
by tiie reply packet 1504.. 

[0056] As illustrated in Fig. 1 6, a session release indi- 
cation 1 601 is issued from the application layer of a des-. 
tination node to its link layer, which responds with the 
ti-ansmission of a session release packet 1602 to the 
multicast manager 10D. The node count value at tiie 
multicast manager is decremented by one. The applica- 
tion layer at a source node monitors the arrival of reser- 
vation messages. If they do not arrive for a 
predetermined interval, the source node application 
layer issues a session release indication 1603 to its link 
layer, which responds with the transmission of a session 
release packet 1604 to the multicast manager, which 
decrements the node count value by one. If the node 
count value reduces to zero, the multicast manager 
sends a channel release packet 1605 to the iso- 
chronous resource manager to release the ownership of 
tiie allocated channel number and bandwidth. 

Claims 

1 . A communication network comprising : 

a plurality of IEEE-1394 nodes connected to a 
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serial bus, each of the nodes functioning as a 
source node or a destination node for signaling 
an asynchronous channel setup request con- 
taining a multicast address and signaling an 
asynchronous channel release request: arri 5 
a multicast manager connected to said serial 
txjs, said multicast manager comprising a 
channel allocation tat)le having a plurality of 
entries each mapping a channel number to a 
nrulticast address. 10 
said multicast manager being responsive to 
said asynchronous channel setup request for 
making a search through said table, setting a 
node count value to 1 , acquiring ownership of a 
channel number from an IEEE-1394 iso- is 
chronous resource manager and mapping the 
acquired channel number to the multicast 
address of said request in a corresponding 
entry of said table if no channel number was 
mapped to said multicast address during said 20 
search or incrementing the node count value 
by 1 if a channel number is mapped to said 
multicast address during said search, and sign- 
aling a reply message on said bus. 
said source node being responsive to said ss 
reply message from the multicast manager for 
multicasting asynchronous stream packets to 
said bus. • . ^ 

said multicast manager being responsive to 
said asynchronous channel release request for 30 
deaementing the node count value by 1. said 
multicast manager restoring the ownership of 
said channel. numl>er to said isochronous'.^^-?' 
resource manager and clearing the corre- .•• 
spending :entry of said tak)le when said node . 35 ^' . 
count' valueequals zero. ■ ■ .:.vrj-7r;vv-. 

2. The communication- network of claim 1. wherein " r - 
said source node is arranged to signal said asyn- w 
chronous channel release request on said serial 40 
bus if there is no asynchronous stream packet to be 
produced on said serial bus for a predetermined 
period of time. 

3. The communication network of claim 1. wherein 45 
each of said source node and said destination node 
is arranged to signal on said bus an isochronous 
channel setup request containing session data and 
signaling an isochronous channel release request. 

50 

said multicast manager being responsive to 
said isochronous channel setup request for 
making a search through said table, setting a 
node count value to 1 . acquiring ownership of a 
channel resource from said isochronous ss 
resource manager and mapping a channel 
number of said acquired channel resource to 
the session data of said request in a corre- 




sponding entry of said table if no channel 
number was mapped to said session data or 
incrementing the node count value by 1 if a 
channel number is mapped to said session 
data, and signaling a reply message on said 
bus. 

said source node being responsive to a said 
reply message from the multicast manager for 
multicasting isochronous packets to said bus. 
said multicast manager being responsive to 
said channel release request for decrementing 
the node count value by 1 . said multicast man- 
ager restoring the ownership of said channel 
resource to said isochronous resource man- 
ager and clearing the corresponding entry of 
said table when said node count value equals 
zero. 

4. A communication network comprising : 

a plurality of IEEE-1394 nodes connected to a 
serial txjs. each of the nodes functioning as a 
source node or a destination node for signaling 
an isochronous channel setup request contain- 
ing session data and signaling an isochronous 
channel release request; and 
a multicast manager connected to said serial 
bus. said multicast manager comprising a 
channel allocation table having a plurality of 
entries each mapping a channel number to 
session data. 

said multicast manager being responsive to 

said isochronous channel setup request for . • . . »fi-: nc- 

making a search through said taksle, setting a ^ * ;V - v.%fe^rrj 
node count value to 1 . acquiring ownership of a ^' rh -v- * 

channel number and necessary channel ..r : j' :;:r ^ 
resource from an IEEE-1394 isochronous 7 -y.^c 

resource manager and mapping said channel . . ■ >' 
number and said necessary channel resource \ ' r: .s.- 

to the session data of said request in a corre- 
sponding entry of said table if no channel 
nunriber was mapped to said session data dur- 
ing said search or incrementing the node count 
value by 1 if a channel number is mapped to 
said session data during saki search, and sign- 
aling a reply message, 

said source node being responsive to sakJ 
reply message for multicasting isochronous 
packets to said bus, . 

said multicast manager being responsive to 
said isochronous channel release request for 
decrementing the node count value by 1 . said 
multicast manager restoring the ownership of 
said channel number and said channel 
resource to said isochronous resource man- 
ager and clearing the corresponding entry of 
said table when said node count value equals 
zero. 
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a pluralrty of IEEE-1394 nodes connected to a 
serial bus. each of the nodes functioning as a 
source node for signaling a path message indi- 5 
eating session data and functioning as a desti- 6. 
nation node for receiving said path message 
and signaling a first isochronous channel setup 
request containing the session data Indicated 
in said path message, each of said source and io 
destination nodes signaling an isochronous 
channel release request; and 7. 
a multicast manager connected to said serial 
bus. said multicast manager comprising a 
channel allocation table having a plurality of is 
entries each mapping a channel number to 
session data. 

said multicast manager being responsive to 
said first isochronous channel setup request for 
making a search through said table, setting a 20 
node count value to 1 . acquiring ownership of 
an isochronous channel number from an lEEE- 
1 394 isochronous resource manager and map- 
ping the acquired channel number to the ses- 
sion data of said request in a corresponding 2S 
entry of said table if no channel number was 
mapped to said session data during said 
search or incrementing the node count value 
by 1 if a channel numk>er is mapped to said 
session data during said search, and signaling 30 
a first reply message, 

said destination node being responsive to said 
first reply message for signaling a reservation 
message indicating a desired ^ channel 
resource, and said source node being, respon- 35 
sive to said reservation message for signaling a 
second ' isochronous channel setup request 
containing the . channel - resource indicated in 
.said reservation message. . - . . . 
said multicast manager being responsive to 4o 
said second isochronous channel setup 
request for determining necessary channel 
resource from a resource value in said corre- 
sponding entry of the allocation table, acquiring 8. 
ownership of the necessary channel resource 45 
from saki isochronous resource manager and 
updating the resource value with the acquired 
channel resource and signaling a second reply 
message on said bus, 

said source node being responsive to said sec- so 
ond reply message from the multicast manager 
for multicasting isochronous packets to said 
bus. 

said multicast manager being responsive to 
said isochronous channel release request for ss 
decrementing the node count value by 1 . said 
multicast manager restoring the ownership of 
said channel number and said channel 



resource to said isochronous resource man- 
ager and clearing the corresponding entry of 
said table when said node count value equals 
zero. 

The communication network of daim 5. wherein 
said source node is arranged to signal said iso- 
chronous channel release request when said reser- 
vation message is not produced on said bus for a 
predeterodned interval of time. 

A communication method for a network including a 
plurality of IEEE-1394 nodes connected to a serial 
txjs. one of said nodes comprising a channel allo- 
cation tat)le having a plurality of entries, the method 
comprising tiie steps of: 

a) signaling a request for an asynchronous 
channel from one of said nodes either function- 
ing as a source node or a destination node: 

b) making a search through said table; 

c) if no channel number is mapped to a multi- 
cast address contained in said request, setting 
a node count value to 1 , acquiring ownership of 
a channel number from an IEEE-1394 iso- 
chronous resource manager and mapping tiie 
acquired channel number to the multicast 
address in a con^esponding entry of said table; 

d) if a channel number is mapped to said multi- 
cast address, incrementing tiie node count 
value by 1 ; 

e) multicasting asynchronous stream packets 
from said source node to said bus; 

f) requesting release of the channel from one of 
said nodes; 

g) deaementing the node count value by 1 ; 
and 

h) repeating the steps (a) to (g) until said node 
count value equals zero, restoring the owner- 
ship of said channel number to sakH iso- 
chronous resource manager and clearing the 
corresponding entry of said table. 

The communication method of claim 7, further com- 
prising tiie steps of: 

A) signaling a request for setting up an iso- 
chronous channel from one of said nodes 
either functioning as a source node or a desti- 
nation node; 

B) making a search through said table; 

C) if no channel number is mapped to session 
data contained in said request, setting a node 
count value to 1 . acquiring ownership of an iso- 
chronous channel resource and a channel 
nuntoer of said resource from said isochronous 
resource manager and mapping said channel 
number and said channel resource to the ses- 
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sion data of said request in a corresponding 
entry of said table: 

D) if a channd number is mapped to said ses- 
sion data, incrementing the node count value 

by 1: 5 

E) multicasting isochronous packets from said 
source node to said bus; 

F) signaling a request for releasing said chan- 
nel from one of said nodes: 

G) decrementing the node count value by 1; io 
and 

H) repeating the steps (A) to (G) until said node 
count value equals zero, restoring the owner- 
ship of said channel resource and said channel 
number to said isochronous resource manager is 
and clearing the corresponding entry of said 
table. 

. The communication method of daim 7, further com- 
prising the steps of: so 

A) sending a path message indicating session 
data from one of said nodes when functioning 
as a source node; 

B) receiving, at one of said nodes when func- 25 
tioning as a destination node, said path mes- 
sage and signaling a first request for setting up 

an isochronous channel; 

C) making a search through said table; 

• D) if no channel number is mapped to session 30 
data contained in said request setting a node 
count value to 1 . acquiring ownership of an iso- 
. '\^<;^::;Vchronous channel number from said iso- 
[t--^;-' : .'chronous resource manager and mapping the 

- acquired channel number to the session data 35 
. r.H^v of said request in a corresponding entry of said 
- table; 

' > E) if a channel number is mapped to said ses- 
sion data, incrementing the node count value 
by 1; 40 

F) sending a reservation message from the 
destination node to said source node, said 
message containing a channel resource which 
the destination node wishes to receive; 

G) signaling from said source node a second 45 
request containing the channel resource indi- 
cated in said reservation message; 

I) determining necessary channel resource 
from the channel resource contained in said 
second request and from a resource value in so 
said corresponding entry of the allocation table, 
acquiring ownership of the necessary channel 
resource from said isochronous resource man- 
ager and updating the resource value with the 
acquired channel resource; 55 
J) multicasting isochronous multicast packets 
from said source node to said bus; 

K) signaling from either of said source or desti- 



nation node a request for releasing the chan- 
nel; 

L) decrementing the node count value by 1; 
and 

M) repeating the steps (A) to (L) until said node 
count value equals zero, restoring the owner- 
ship of said channel nun^er and said channel 
resource to said isochronous resource man- 
ager and clearing the corresponding entry of 
said table. 

10. A communication method for a network including a 
plurality of IEEE-1394 nodes connected to a serial 
bus. one of said nodes comprising a channel allo- 
cation table having a plurality of entries each map* 
ping a channel numt^er to session data, the method 
comprising the steps of: 

a) signaling a request for setting up an iso- 
chronous channel from one of said nodes 
either functioning as a source node or a desti- 
nation node; 

b) making a search through said table; 

c) if no channel number is mapped to session 
data contained in said request, setting a node 
count value to 1, acquiring ownership of a 
channel number and an isochronous channel 
resource from an IEEE-1394 isochronous 
resource manager and mapping the acquired 
channel number and said channel resource to 
the session data of said request in a corre- 
sponding entry of said table; 

d) if a channel.number is mapped to said ses-..' 
sion data, incrementing the node count value' 
by 1; ... . • 

e) multicasting isochronous packets from said * 
source node to said t)us; . ^: . 

f) signaling a request for releasing the channel 

resource; . " . _ - . - 

g) decremerrting the node count value by 1; 
and 

h) repeating the steps (a) to (g) until said node 
count value equals zero, restoring the owner- 
ship of said channel number and said channel 
resource to said isochronous resource man- 
ager and clearing the corresponding entry of 
said table. 

11. A communication method for a network including a 
plurality of iEEE-1394 nodes connected to a serial 
bus. one of said nodes comprising a channel allo- 
cation table having a plurality of entries each map- 
ping a channel number to a multicast address, the 
method comprising the steps of: 

a) sending a path message from one of said 
nodes when functioning as a source node; 

b) receiving, at one of said nodes when func- 
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tiordng as a destination node, said path mes- 
sage and signaling a first request for setting up 
an isochronous channel; 

c) making a search through said tatrfe; 

d) if no channel nunrtoer is mapped to session s 
data contained in said first request, setting a 
node count value to 1 . acquiring ownership of 
an isochronous channel number from an IEEE- 
1394 isochronous resource manager and map- 
ping the acquired channel number to the ses- io 
sion data of said request in a conresponding 
entry of said table; 

e) if a channel number is mapped to said ses- 
sion data, incrementing the node count value 

by 1 ; IS 

f) sending from said destination node a reser- 
vation message containing a channel resource 
the destination node wishes to receive; 

g) signaling a second request from said source 
node, said request corrtaining the channel 2o 
resource indicated in said reservation mes- 
sage; 

h) determining necessary channel resource 
from the channel resource indicated in the sec- 
ond request and from a resource value in said 2S 
conesponding entry of the allocation table, 
acquiring ownership of the necessary channel 

resource from said isochronous resource man- . . r . : 

ager and updating said resource value with the 
acquired channel resource; 3o 

i) multicasting isochronous packets from said ..... 
source node to said bus in response to said 

second reply 'request; V ; ■ ^'^^jy 

j) signaling: a request'for releasing the channel -.v . 5-A:r> -:v^>.ix- 

resource from either .of said source or destina- 35- v , v.. ^: 'ov-c" - 

tion hode;-'"^!.' /• >:!;■ ^ - .:■•.«:■--.».•. . > . 

k) decrementing-^the.node count value by 1; -j. \ . -r-. -rr/ ^ 

and :VTi\/'- V. "v.* ■ . 

I) repeating the steps (a) to (k) until said node - ^ • 't? ' ""^'ci. 

count value equals zero, restoring the owner- 40 
ship of said channel number and the acquired 
channel resource to said isochronous resource 
manager and clearing the corresponding entry 
of said table. 
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